Method for controlling access to content implemented by a cache server

ABSTRACT

A content distribution network is made up of terminals and servers that are connected as a network and cooperate in order to make content or data available to users. In order to be able to control access to the content via certain terminals, a solution called “URL signing” has been discussed. A “URL signing” solution requires establishing an active connection between a terminal requesting content and an originating server associated with the requested content. The solution relates to a method for accessing content implemented by a cache server, thus dispensing with the need for an active connection between a terminal requesting content and the originating server associated with the requested content.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is filed under 35 U.S.C. § 371 as the U.S. NationalPhase of Application No. PCT/FR2021/051153 entitled “METHOD FORCONTROLLING ACCESS TO CONTENT IMPLEMENTED BY A CACHE SERVER” and filedJun. 23, 2021, and which claims priority to FR 2006709 filed Jun. 26,2020, each of which is incorporated by reference in its entirety.

BACKGROUND Field

The field of the development is that of content delivery to at least oneterminal.

More particularly, the development relates to a method for controllingaccess to content stored in a so-called cache server by at least oneterminal.

Description of the Related Technology

A content delivery network (CDN) is made up of terminals and serversthat are connected as a network and cooperate in order to make contentor data available to users.

Such a content delivery network is made up of: originating servers, fromwhich content is “injected” into the CDN for being replicated therein;peripheral servers, typically deployed in several geographicallydistinct locations, where content from the originating servers isreplicated; a routing mechanism allowing a content access request sentby a user terminal to be served by the “closest” server, in order tooptimise the transmission/delivery mechanism.

In order to be able to control access to content via some terminals, asolution called “URL signing” has been discussed within the context ofan IETF (Internet Engineering Task Force) working group and formalisedin the documenthttps://tools.ietf.org/html/draft-ietf-cdni-uri-signing-19.

FIG. 1 represents a diagram of message exchanges between differentterminals contributing to the implementation of such a “URL signing”solution.

The system comprises at least one terminal 10 requesting access to atleast one content, such as a web page or a multimedia content, a cacheserver 11, and at least one originating server 12 whose namingidentifier is for example journal.fr, hosting at least one content to bedelivered, for example a web page referenced journal.fr/news/week19 andstoring data relating to the content requested by the terminal 10 suchas data relating to the web page joumal.fr/news/week19 or data relatingto downloadable content, etc.

The terminal 10 can exchange messages with the cache server 11 and withthe originating server 12. A terminal 10 is a piece of equipment thatcan send requests to obtain content, such as a personal computer, a homegateway, a digital television set-top box, a smartphone, a sensor, etc.

Thus, in a step E1, the terminal 10 sends a request to access content tothe originating server 12.

In a step E2, the originating server 12 generates a URI (UniformResource Identifier) resource identifier associated with the requestedcontent and the requesting terminal 10. This URI resource identifiercomprises additional information for controlling access to this contentby the terminal 10, such as, for example, a cryptographic key.

During a step E3, the originating server 12 transmits a message to theterminal 10 comprising the resource identifier generated during step E2.

The receipt of the message transmitted by the originating server 12during step E3 triggers, in a step E4, a step of transmitting, by theterminal 10, a request for access to the requested content to a cacheserver 11 in which the requested content is stored. The access requestthus transmitted comprises additional information for controlling accessto the requested content. Step E4 is equivalent to redirecting a contentaccess request to the originating server to the cache server 11. Indeed,from a protocol point of view, the request to access the content sent bythe terminal 10 during step E1 to the authoritative server is redirectedto the cache server 11 during step E4. Indeed, although the two requestsunder consideration have a different content, the second requestcomprising the additional information for controlling the access to therequested content, they are perceived, from a protocol point of view, asone and the same request relating to the access to a same content by asame terminal 10.

Upon receipt of the content access request comprising the additionalinformation for controlling access to the requested content, the cacheserver 11 verifies, in a step E5, the authenticity of the content accessrequest by means of the additional information for controlling access tothe requested content comprised in the request and by means ofinformation relating to the right of access to the requested contentpreviously provided by the originating server 12 to the cache server 11.

When the authenticity of the content access request is verified, thecache server 11 delivers the content to the terminal 10 during a stepE6.

Such a so-called “URL signing” solution requires the availability of theoriginating server at the time of the request in order for a connectionto be established between the terminal 10 and the originating server 12,since the content access request received by the cache server 11 havingthe requested content corresponds to redirecting the initial accessrequest transmitted by the terminal 10 to the originating server 12.

Because of this restriction, this “URL signing” solution is not verywell adapted to the requirements of the 5G standard (or 5th generationstandards for mobile telephony), in particular in terms of exchangeprocessing time due to the redirection of the initial access request.

Another drawback of this “URL signing” solution is the increase in loadfor the domain hosting the originating server of the content when therequested content is required by a large number of users. Indeed, themore content is downloaded, the more the number of content accessrequests sent to the originating server 12 increases. However, domainshosting originating servers of contents, having delegated the deliveryof this content to content delivery networks, are not always sized tohandle a substantial load.

There is therefore a need for a content access control technique thatdoes not have all or part of these drawbacks.

SUMMARY

The development meets this need by providing a method for accessing atleast one content, said method being implemented by a terminal andcomprising:

-   -   a first phase comprising the following steps of:        -   sending a request for authorisation to access said at least            one piece of content to an originating server associated            with said content,        -   receiving a file comprising at least said authorisation to            access said content, the file being delivered by the            originating server, a second phase comprising the following            steps of:        -   sending a request for access to said content to a so-called            cache server in which said content is stored,        -   transmitting the file comprising said access authorisation            to the cache server,        -   receiving the content transmitted by the cache server when            the authenticity of the file is verified by the cache            server.

Such a method for accessing content implemented by a cache server makesit possible to dispense with the need for a connection between aterminal requesting content and the originating server associated withthe requested content. By content, it is meant a specific content or aset of contents located on branches of a same URL (Uniform ResourceLocator). For example, a naming identifier journal1.fr/news is common totwo contents respectively referenced journal1.fr/news/week19 andjournal1.fr/news/week20.

In addition, such a method for accessing content makes it possible toshift the load induced at the domain hosting the originating serverassociated with this content by an increase in the number of requestsfor access to a given content to a content delivery network, since theprocessing of content access requests by the originating serverassociated with the requested content then the control of theauthorisation by the cache server located in a content delivery networkare no longer synchronous. Indeed, these two actions can be decorrelatedin time.

Indeed, in the present solution, during a first phase, the terminal isprovided by an originating server associated with the requested contentwith a file containing an authorisation to access said content. Theproviding of this file by the originating server is triggered by thereceipt, by the originating server, of a request for authorisation toaccess a given content. Once the file is provided, it is no longernecessary to maintain a connection between the terminal and theoriginating server.

During a second phase, which may be implemented subsequently to thefirst phase or several hours or days later, a user of the terminalactually wishes to actually access the content. For this, the terminaltransmits a request for access to the requested content to a cacheserver, an identifier of which may be provided to the terminal by theoriginating server, in which the requested content is stored. The cacheserver then performs access control to the content by means of the filecomprising an authorisation to access said content provided by theterminal and received by the latter from the originating serverassociated with the requested content and when it is verified that theaccess authorisation is authentic, the cache server delivers the contentto the terminal.

In one particular embodiment of the method for accessing content, saidfile comprises a sequence of messages exchanged between the terminal andthe originating server during a communication session establishedbetween the terminal and the originating server, at least one of themessages of said sequence of messages comprising said authorisation toaccess said content.

This makes it possible to increase the reliability level of theverification of the authenticity of the access authorisation of theterminal. Indeed, by having access to the entirety of the exchangesbetween the terminal and the originating server, the cache server isable to ensure the authenticity and integrity of both.

According to a particular characteristic of the method for accessingcontent, the content reception step consists in replaying, with saidcache server, a sequence of messages exchanged between the cache serverand the so-called originating server during a communication sessionestablished between the cache server and the originating server duringwhich said content was delivered to the cache server, said sequence ofmessages having been recorded by said cache server.

By delegating the content delivery to cache servers, it is possible toreduce the costs related to the execution of this content deliveryfunction. Indeed, by delegating the content delivery to a cache serverit is possible to reduce the number of connections between communicationpieces of equipment in order to deliver contents, in particular byreusing the existing connections between the user pieces of equipmentand the cache servers. Such a reduction in the number of connectionsbetween communication devices leads to a reduction in the energyconsumption of these communication devices.

Unlike known “caching” techniques in which the content itself is storedin at least one cache memory of a cache server, the solution provided isbased on storing in the cache server an identical copy of all themessages exchanged between the original server hosting the content andthe cache server leading to the delivery of the content to the cacheserver.

The replay can be carried out to several terminals at the same time in asame so-called IP multicast point-to-multipoint connection as describedin the documenthttps://tools.ietf.org/html/draft-pardue-quic-http-mcast-00 #section-3published by the IETF.

Thus, when a terminal wishes to access a given content, the cache serverreplays with the terminal the sequence of messages previously exchangedbetween the originating server hosting the content and the cache serverthat led to the delivery of the content to the cache server. The termreplay consists in repeating, by the cache server and with the terminal,the sequence of messages exchanged between the originating server andthe cache server when downloading the requested content, the replayedmessages being able, if necessary, to be modified to adapt to thecontext in which they are replayed.

Such a content delivery delegation solution also has increasedperformance. This is because the number of connections establishedbetween communication pieces of equipment in order to deliver content isreduced.

Finally, the content delivery solution provided is reliable. Indeed,within the context of the content delivery method described, a cacheserver implementing a content delivery is provided with an authorisationto execute this content delivery function which can be verified ifnecessary.

According to another particular characteristic of the method foraccessing content, said access authorisation has a validity duration.

Once the validity duration has expired, the terminal can no longeraccess the content. This makes it possible to limit the distribution ofa given content.

The development also relates to a method for controlling access tocontent stored in a so-called cache server by at least one terminal,said method being implemented by the cache server and comprising:

-   -   a first phase comprising the following step of:    -   receiving a first file comprising data for controlling access to        said content delivered by a so-called originating server        associated with said content,    -   a second phase comprising the following steps of:    -   receiving a request for access to said content sent by said        terminal,    -   receiving a second file, transmitted by the terminal and        comprising at least one authorisation to access said content        delivered to said terminal by the originating server,    -   verifying the authenticity of the second file comprising said        authorisation to access said content by means of the first file        comprising data for controlling access to said content,    -   when the authenticity of the second file is verified, delivering        the content to said terminal.

According to one particular embodiment of the access control method, thefirst file further comprises software for processing said second file.

Such software enables the data comprised in the second file to beprocessed in order to verify the authenticity and integrity of the data.

Such software may be specific to one or more series of particularterminals, for example all the terminals of a certain range of a givenmanufacturer.

This software may be developed and supplied by a third party, be in theform of an application, etc.

According to another particular embodiment of the access control method,it comprises a step of recording a sequence of messages exchangedbetween the cache server and the originating server hosting the contentduring a communication session established with the originating serverassociated with said content and during which said content is deliveredto the cache server.

In one particular implementation of this other embodiment of the accesscontrol method, the first file is delivered during said communicationsession established with the originating server.

This limits the exchanges between the cache server and the originatingserver, which contributes to increasing performance.

In another particular implementation of this other access controlmethod, the method comprises a step of replaying, with said at least oneterminal, the sequence of messages recorded, resulting in the deliveryof said content.

In another particular embodiment of the access control method, thesecond file comprises a sequence of messages exchanged between theterminal and the originating server during a communication sessionestablished between the terminal and the originating server, at leastone of the messages of said sequence of messages comprising saidauthorisation to access said content.

The development relates to a so-called cache server capable ofcontrolling access to content stored in the so-called cache server by atleast one terminal, the cache server comprising means for:

-   -   receiving a first file comprising data for controlling access to        said content delivered by a so-called originating server        associated with said content,    -   receiving a request for access to said content sent by said        terminal,    -   receiving a second file, transmitted by the terminal and        comprising at least one authorisation to access said content        delivered to said terminal by the originating server,    -   verifying the authenticity of the second file comprising said        authorisation to access said content by means of the first file        comprising data for controlling access to said content,    -   when the authenticity of the second file is verified, delivering        the content to said terminal.

Another object of the development relates to a terminal requestingaccess to content, said terminal (10) comprising means for:

-   -   receiving a file comprising at least one authorisation to access        said content delivered to said terminal by an originating server        associated with said content,    -   sending a request for access to said content to a so-called        cache server in which said content is stored,    -   transmitting the file comprising said access authorisation to        the cache server,    -   receiving the content transmitted by the cache server when the        authenticity of the file is verified by the cache server.

The development finally relates to computer program products comprisingprogram code instructions for implementing the methods as describedabove, when executed by a processor.

The development also relates to a computer-readable recording medium onwhich computer programs comprising program code instructions forexecuting the steps of the methods according to the development asdescribed above are stored.

Such a recording medium may be any entity or device capable of storingthe programs. For example, the medium may have a storage medium, such asa ROM, for example a CD ROM or a microelectronic circuit ROM, or amagnetic recording medium, for example a USB key or a hard disk.

On the other hand, such a recording medium may be a transmissible mediumsuch as an electrical or optical signal, which may be conveyed via anelectrical or optical cable, by radio or by other means, so that thecomputer programs contained therein are remotely executable. Theprograms according to the development may in particular be downloadedover a network, for example the Internet.

Alternatively, the recording medium may be an integrated circuit inwhich the programs are incorporated, the circuit being adapted toexecute or to be used in the execution of the aforementioned methods,objects of the development.

BRIEF DESCRIPTION OF THE DRAWINGS

Other purposes, characteristics and advantages of the development willbecome clearer upon reading the following description, given merely asan illustrative, and non-limiting, example in connection with thefigures, among which:

FIG. 1 : this figure represents a diagram of message exchanges betweendifferent terminals contributing to the implementation of such a “URLsigning” solution,

FIG. 2 : this figure represents a system in which the methods objects ofthe development are implemented,

FIG. 3 : this figure represents a diagram of exchanges between differentcommunication pieces of equipment involved in the implementation of themethods for accessing at least one content and for controlling access toat least one content,

FIG. 4 : this figure represents a terminal capable of implementing thedifferent embodiments of the method for accessing at least one contentaccording to FIG. 3 ,

FIG. 5 : this figure represents a cache server capable of implementingthe different embodiments of the method for controlling access tocontent according to FIG. 3 .

DETAILED DESCRIPTION OF CERTAIN ILLUSTRATIVE EMBODIMENTS

The general principle of the development is based on the delegation ofaccess control usually performed by originating servers hosting contentsto be delivered, called originating servers of contents in thefollowing, to cache servers, such as web servers, managed for example byan Internet service provider. Such cache servers implement an“intermediate cache” function and are called in the following cacheservers.

Thus, a cache server stores, in at least one of its cache memories,contents transmitted by the originating servers of said contents as wellas one or more files associated with these contents and comprising datamaking it possible to perform the operations for controlling access tothese contents in the place of the originating server. When anauthorisation for access to content transmitted by a terminal isverified, the cache server transmits this content to a client embeddedin the terminal without reconnecting to the originating server of thecontent identified in a request requiring the providing of the content.

A system in which the methods being objects of the development areimplemented is now represented in connection with FIG. 2 .

The system comprises at least one terminal 10 requesting access to atleast one resource corresponding to a content by means of a URLidentifying said resource, such as a web page or a multimedia content, acache server 11 whose naming identifier is for example orange.fr, and atleast one originating server 12 whose naming identifier is for examplejoumalfr, hosting at least one content to be delivered, such as a webpage referenced joumalfr/news/week19 and storing data relating to thecontent requested by the terminal 10 such as data relating to the webpage joumalfr/news/week19 or data relating to downloadable content, etc.For example, this is a newspaper consisting of web pages with differenttypes of contents such as text, images, videos, sound files, 3Danimations, etc.

The terminal 10 can exchange messages with the cache server 11 and withthe originating server 12. A terminal 10 is a piece of equipment thatcan send requests to obtain content such as a personal computer, a homegateway, a digital television set-top box, a smartphone, a sensor, etc.

These various exchanges of messages between these different pieces ofequipment and their contents are explained in more detail in thefollowing.

FIG. 3 shows a diagram of exchanges between different communicationpieces of equipment involved in the implementation of the methods foraccessing at least one content and for controlling access to at leastone content.

In a step G1, the cache server 11 establishes a communication sessionwith the originating server 12 associated with at least one givencontent during which the content is delivered to the cache server 11.

The sending by the cache server 11 of an http get message triggers thecontent delivery procedure.

In a first embodiment of the methods objects of the development, in aconventional manner, the content itself is delivered to the cache server11 by the originating server 12 and stored in at least one cache memoryof the cache server 11 during a step G2.

In a second embodiment of the methods objects of the development, unlikeknown “caching” techniques in which the content itself is stored in atleast one cache memory of the cache server 11, the methods objects ofthe present development are based on the storage in at least one cachememory of the cache server 11 of all the messages exchanged between theoriginating server 12 and the cache server 11 leading to the delivery ofthe content to the cache server 11. In this second embodiment, thepreviously described step G2 is not implemented.

During a step G3, the originating server 12 generates protocolinformation such as signalling information, as http headers, cookies,access control, etc., and/or control information to be used whendelivering the content to a terminal 10,

The protocol information generated is for example a list of headerfields that can be adapted. Such a JSON PATCH list is for example thefollowing:

[ { “op”: “replace”, “path”: “user-agent”, “value”: “w” }, { “op”:“add”, “path”: “any”, “value”: “any”}, // the cache can add the fieldsit wants ]

The protocol information generated may comprise instructions to changethe protocol or protocol version used when downloading content betweenthe originating server 12 and the cache server 11 in order to adapt tothe protocol used by the terminal 10.

Finally, the protocol information generated may also compriseinstructions to change the time spacing between messages to reducethroughput, and indicate these changes in control messages.

The protocol information thus generated by the originating server 12 isthen certified by the originating server 12 using cryptographicparameters derived, inter alia, from a private key associated with apublic key of the originating server 12. Thus, the integrity of theprotocol information thus generated is guaranteed.

In a step G4, the cache server 11 stores, in at least one of its cachememories, all the messages exchanged, or played, with the originatingserver 12 associated with said content which follow the sending of thehttp get message in a file of the HARS (http archive secure) type, forexample, the so-called content delivery file FLC. The HARS format allowsmessages to be stored in a so-called “opaque” form, that is, unchanged,or in an interpretable form, or in a mixed form in order to keep thedata messages in encrypted form while leaving all or part of thesignalling information readable.

All the messages recorded by the cache server 11 comprise messagescomprising the protocol information generated and certified by theoriginating server 12 as well as all the messages conventionallyexchanged between the originating server 12 and the cache server 11 whendownloading a given content. The messages conventionally exchangedbetween the originating server 12 and the cache server 11 whendownloading a content constitute the primitive form corresponding to thepacket flows exchanged when downloading these contents.

An example of the messages exchanged between the originating server 12and the cache server 11 is represented below:

HTTP2_SESSION_INITIALIZED --> protocol = “h2 --> source_dependency =206050 (SOCKET) HTTP2_SESSION_SEND_SETTINGS --> settings = [“[id:1(SETTINGS_HEADER_TABLE_SIZE) value:65536]”HTTP2_SESSION_UPDATE_RECV_WINDOW --> delta = 15663105 --> window_size =15728640 HTTP2_SESSION_SEND_WINDOW_UPDATE --> delta = 15663105 -->stream_id = 0 HTTP2_SESSION_SEND_HEADERS --> exclusive = true --> end =true --> has_priority = true -->:method: POST :authority:www.youtube.com :scheme: https :path:/api/stats/qoe?event=streamingstats&fmt=243&afmt=251 content-length: 0pragma: no-cache cache-control: no-cache sec-fetch-mode: no-cors origin:https://www.youtube.com user-agent: Mozilla/5.0 (Windows NT 10.0; Win64;x64) dnt: 1 content-type: text/plain;charset=UTF-8 accept: */*x-client-data: CJa2yQEIpLbJAQjBtskBCKmdygEI4qjKAQjt sec-fetch-site:same-origin

At the end of this recording, the messages comprising the protocolinformation generated and certified by the originating server 12 as wellas all the messages conventionally exchanged between the originatingserver 12 and the cache server 11 when downloading a content are storedin the cache server 11. These messages are stored in a HARS file, theso-called content delivery file FLC, which is itself stored in the cacheserver 11.

The HARS record format makes it possible to store in a file, or anarchive, the different messages carrying the protocol informationgenerated by the originating server 12 and the different data messagesexchanged, or played, when downloading the content between theoriginating server 12 and the cache server 11. Such messages are, forexample, compliant with the HTTP2 or QUIC protocols.

In a step G5, the originating server 12 generates an access control fileFCA comprising data for controlling access to the resource associatedwith the given content and identified by a URL. The data comprised inthis access control file FCA is either specific to a given terminal 10,or generic and may, for example, apply to a given model of terminalwhile being specific to the requested content, or generic with respectto the terminal and with respect to the requested content, in the lattercase, it then applies to all the resources of the originating server 12.

The access control file FCA may comprise software for processing anaccess authorisation or a file comprising such an access authorisation.The access control file FCA may also comprise other data such asparameters relating to the volume of content that can be downloaded by asame terminal, an access duration to one or more given contents.

The access control file FCA is a HARS file.

In a step G6, the originating server 12 transmits the access controlfile FCA to the cache server 11.

In one particular implementation of the first embodiment, the accesscontrol file FCA is transmitted to the cache server 11 together with thecontent during step G2. In this particular implementation of the firstembodiment, step G6 is not implemented and step G5 is implemented priorto step G2.

In one particular implementation of the second embodiment, the accesscontrol file FCA is transmitted by the originating server during thesame series of message exchange that leads to the delivery of thecontent during step G4. In this particular implementation of the secondembodiment, the cache server 11 stores, in at least one of its cachememories, all the messages exchanged, or played, with the originatingserver 12 and relating to the delivery of the content in a HARS typefile, the so-called content delivery file FLC, as well as the accesscontrol file FCA. The content delivery file FLC and the access controlfile FCA are two separate files. In this particular implementation ofthe second embodiment, step G6 is not implemented and step G5 isimplemented prior to step G4. Step G5 may be implemented before, afteror concurrently with step G3.

At the end of steps G2, G4 or G6, depending on the implementationimplemented, the cache server 11 has the required content comprised inthe content delivery file FLC and the content access control file FCA.

In one particular embodiment, the content delivery file FLC and theaccess control file FCA are recorded by the cache server 11 in a commonHARS file, for example in two distinct streams of the HTTP2 or QUICprotocols. In this particular embodiment, the originating server 12transmits, during exchanges with the cache server 11, JSON PATCHinstructions, as defined for example in the documenthttps://tools.ietf.org/html/rfc6902 #section-4.6 published by the IETFand described below, so that the cache server 11 removes the dataconstituting the access control file FCA at the time of delivery of thecontent to the terminal 10:

[ { “op”: “remove”, “path”: “/FCA/*” }, // request to delete thedelivery of FCA control parameters ]

Steps G1 to G6 do not directly trigger steps G7 and the following steps,but have to precede the same in order to ensure the proper execution ofthe methods for controlling access to content and for accessing content.

In a step G7, the terminal 10, a user of which wishes to access a givencontent, sends a message, for example of the http GET type comprisingthe URL of a resource associated with the requested content, to theoriginating server 12 associated with the required content. Such amessage comprises at least an identifier of the originating server 12and an identifier of the requested content.

During a step G8, the originating server 12 generates an authorisationto access the required content in response to receiving the http GETmessage.

The access authorisation generated by the originating server 12 is, forexample, comprised in a file, the so-called access authorisation fileFAA. Such an access authorisation file FAA is a HARS file comprising allthe messages as they have been exchanged between the terminal 10 and theoriginating server 12 associated with said content, starting from thesending of the request for authorisation to access the resourceassociated with the requested content sent by the terminal 10 duringstep G7.

In a first implementation, the sending of the request for authorisationto access the resource associated with the requested content is an httpGET URL message sent by the terminal 10 during step G7. The accessauthorisation file FAA then comprises the http GET URL message sent bythe terminal 10 and an http 200 OK message sent by the originatingserver 12. The http 200 OK message sent by the originating server 12constitutes a proof that the originating server 12 authorises theterminal 10 to access the required content.

In this first implementation, the originating server 12 may alsotransmit, among these exchanges, messages comprising identifiers, suchas Internet Protocol (IP) addresses, of cache servers 11 that have therequired content.

These identifiers of cache servers 11 may be comprised in a header of analternate service message such as defined in RFC7838 (Request ForComment) published by the IETF:

-   -   Alt-Svc: h2=“FQDN_A:8000”;    -   Alt-Svc: wpack=“192.168.1.1:8000”;    -   where FQDN_A is a cache server 11 in which the required content        is stored.

These identifiers of cache servers 11 can be transmitted by distributinginformation relating to domain name resolution DNS from a domain nameserver or independent DNS server or from the originating server 12performed according to the DoH resolverless protocol. This informationrelating to DNS name resolution points directly to an IP address, forexample here an IPv4 type address, of the cache server 11 FQDB_A: forexample, ‘A FQDN_B 192.168.1.1:8000’.

These identifiers of cache servers 11 can be further transmitted bydistributing information relating to a so-called redirect DNS resolutionperformed according to the DoH resolverless protocol taking for examplethe form ‘CNAME FQDN_B FQDN_A’, where FQDN_B is the originating server12.

In a second implementation, the originating server 12 behaves as an ACMESTAR (Automatic Certificate Management Environment) server, these twoACME and STAR protocols being defined in the IETF publicationshttps://tools.ietf.org/html/rfc8739 andhttps://tools.ietf.org/html/draft-ietf-acme-star-delegation-01,respectively.

In a known way, the ACME protocol is used to generate X509 certificatessigned by a certification authority. Typically, such certificates aredelivered to one or more cache servers 11 in order to delegate somefunctions of an originating server 12 thereto.

In particular, the ACME protocol is used to automatically generatecertificates for web servers in order to facilitate the migration fromHTTP protocol to HTTPS protocol. The STAR extension of the ACME protocoldefined in document RFC 8739 published by the IETF allows the automaticrenewal of these certificates and thus the generation of certificateswith a short validity duration.

In this conventional implementation of the ACME protocol, authenticationof the originating server 12 to the terminal 10 is achieved usingTransport Layer Security (TLS) protocol compliant messages such as theServerHello message, or when QUIC protocol compliant messages are used,the SHO message. Authentication of the terminal 10 to the originatingserver 12 is performed using an application protocol such as FTP, FTTP,HTTP2, HTTP3, TCP, SCTP, TLS or QUIC protocols located above thetransport layer.

In this second implementation, it is provided to define a new extensionto the HTTP2 protocol named WINS_US_STAR which is based on the ACMEprotocol as defined in document RFC 8739 published by the IETF as wellas the HTTP2 extension defined in documentdraft-ietf-httpbis-http2-secondary-certs also published by the IETF.

In this new HTTP2 protocol extension, a certificate CERT_CLIENT_STAR isa temporary certificate similar to a certificate created using ACMEprotocols with a limited validity duration.

Thus, in this second implementation, the originating server 12 providesa temporary certificate to the terminal 10 that authorises the terminalto access the resource associated with the requested content. Thetemporary certificate provided by the originating server to the terminal10 is derived from a certificate CERT_CLIENT specific to the terminal10.

In a step G7, the terminal 10 establishes a https type secure connectionwith the originating server 12 in accordance with the HTTP2 protocol.During these exchanges, the terminal 10 informs the originating server12 that it supports the WINS_US_STAR extension of the HTTP2 protocol.

During this step G7, the terminal 10 generates a cryptographic key paircomprising a private key WINS_US_PRI and a public key WINS_US_PUBassociated with the certificate CERT_CLIENT of the terminal 10.

The terminal 10 calculates proofs of ownership named WINS_US_CHALLENGE1and WINS_US_CHALLENGE2 respectively of the private key WINS_US_PRI andthe private key WINS_US_PRI by encrypting the URL identifying theresource associated with the requested content using these twocryptographic keys.

Terminal 10 then gathers the proofs of ownership WINS_US_CHALLENGE 1 andWINS_US_CHALLENGE 2, the public key WINS_US_PUB and other parameters forcreating certificates into a new message called WINS_US_CSR. WINS_US_CSRis the equivalent of the Certificate Signing Request (CSR) message inthe ACME protocol.

When establishing the HTTP2 connection with the originating server 12,during step G7, the terminal 10 transmits a request for access to theresource FQDN_B/sth/app comprising:

-   -   a WINS_US=TRUE parameter indicating that it supports the        extension WIN_US_STAR;    -   the request http GET URL FQDN_B/sth/app;    -   the certificate CERT_CLIENT of the terminal 10;    -   a request for a temporary certificate authorising access to the        resource associated with the requested content.

In a step G8, the originating server 12 receives a request for access tothe resource FQDN_B/sth/app sent by the terminal 10.

The originating server 12 detects the presence of the field WINS_US=TRUEwhich indicates that the terminal 10 supports the extension WIN_US.

The originating server 12 then identifies the required resource andverifies the rights of the terminal 10 of access to this resource and tothe content with which it is associated.

The originating server 12 then verifies that decrypting the proofs ofownership WINS_US_CHALLENGE 1 and WINS_US_CHALLENGE 2 using the publickey WINS_US_PUB yields the URL FQDN_B/sth/app identifying the requestedresource.

Once these verifications are performed, the originating server 12generates a certificate CERT_CLIENT_STAR from the certificateCERT_CLIENT of the terminal 10. The originating server 12 includes, in aSAN field (https://fr.wikipedia.org/wiki/Subject_Alternative_Name) ofthe certificate CERT_CLIENT_STAR, at least the URL identifying theresource associated with the requested content such as for example:FQDN_B/sth/app where FQDN_B corresponds to the originating server 12 andwhere/sth/app is the required resource, as well as other parameters suchas parameters relating to the volume of content that can be downloadedby the terminal 10 or to the validity duration of the certificateCERT_CLIENT_STAR.

In a step G9, the originating server 12 transmits the accessauthorisation file FAA to the terminal 10 which stores it in one of itsmemories for later use. In the second implementation, the file FAA ismade up of the certificate CERT_CLIENT_STAR

In a step G10, which may be implemented a few moments, hours or dayslater after the implementation of step G9, the terminal 10 sends amessage, such as an http GET message comprising the URL of the resourceFQDN_B/sth/app identifying the resource associated with the requestedcontent to the cache server 11 indicated in the access authorisationfile FAA. Such a message comprises the URL associated with the requiredcontent FQDN_B/sth/app.

During a step G11, which may be concurrent with or subsequent to stepG10, the terminal 10 transmits the access authorisation file FAA to thecache server 11.

In a step G12, the cache server 11 then proceeds to verify theauthenticity and integrity of the access authorisation file FAA by meansof the access control file FCA.

Thus, the cache server 11 executes the software comprised in the accesscontrol file FCA in order to access the data comprised in the accessauthorisation file FAA.

The processing of the data comprised in the access authorisation fileFAA performed during the execution of the software comprised in theaccess control file FCA verifies the authenticity and integrity of thedata comprised in the access authorisation file FAA and thus theauthorisation to access the required content.

For example, in the first implementation, the software extracts from theaccess authorisation file the URL FQDN_B/sth/app as well as the http 200OK message sent by the originating server 12 which constitutes theauthorisation to access the required content. The software also verifiesif the validity duration of the access authorisation has expired and/orif the volume limit of downloaded data has been reached. Thus, the fileFCA contains parameters for encrypting the session for recording thefiles FAA. The cache server 11 can then read the file FAA and analysethe exchanges contained therein to extract the URL of the resourceassociated with the requested content and in parallel search if thecontent is stored in one of its memories, or extract the response fromthe origin (200 OK).

In the second implementation, the software provided by the originatingserver 12 during step G5 extracts the certificate CERT_CLIENT_STAR andthe URL FQDN_B/sth/app from the access authorisation file FAA. Thesoftware also verifies if the access authorisation validity duration hasexpired and/or if the download volume limit has been reached. Thesoftware provided is not specific to the originating server 12, it makesit possible, when executed, to verify that the CERT_CLIENT_STAR is validand is correctly signed by the originating server 12 using a public keyof a certificate of the originating server 12 obtained in steps G2 orG4.

Verification of the authenticity and integrity of the file FAA by thecache server 11 triggers, in the first embodiment, the delivery of thecontent to the terminal 10 by means of conventional content deliverytechniques in a step G13.

In the second embodiment, the verification of the authenticity andintegrity of the access authorisation file FAA by the cache server 11triggers the replay of the content delivery file FLC stored in the cacheserver 11 and associated with the requested content.

In a first alternative of the methods objects of the development, themodifications to be applied to some messages of the content deliveryfile FLC are performed at the cache server 11. The modifications to beapplied to some messages of the content delivery file FLC consist inmodifying some parameters of the messages stored in the content deliveryfile FLC as a function of the protocol information generated by theoriginating server 12 and also stored in the content delivery file FLC.

In a first implementation of this first alternative, during a step G14,the cache server 11 prepares the replay of the content delivery file FLCassociated with the content with the terminal 10 in order to deliver therequested content to the terminal 10.

For this, the cache server 11 modifies some of the messages stored inthe content delivery file FLC associated with the requested content inorder to adapt them to the sending/receiving points, that is, the cacheserver 11 and the terminal 10, if they are different from those of theinitial set of messages, that is, if they are different from themessages exchanged between the originating server 12 and the cacheserver 11 when downloading the requested content. For this, the cacheserver 11 makes these modifications on the basis of protocol informationgenerated by the originating server 12. The term modification ofmessages stored in the content delivery file FLC covers the addition,the deletion of messages or the modification of some parameters relatingto the messages. Such a list of value modifications is for example:

-   -   user-agent: Mozilla/5.0    -   x-nginx-cache-version: 8.4.1

Once the content delivery file FLC associated with the content is ready,the cache server 11 triggers, in a step G15, the replay of the messagesstored in the content delivery file FLC and modified during step G14.

In a second implementation of this first alternative, the cache server11 modifies some of the messages stored in the content delivery file FLCassociated with the requested content in order to adapt them to thesending/receiving points, when replaying these messages. Thus, in thissecond implementation of this first alternative, the messages that areto be modified are modified gradually.

As in the first implementation, the modification of messages isperformed based on the protocol information generated by the originatingserver 12. Regardless of the implementation, modifications to somemessages of the content delivery file FLC may also change the protocolused when downloading content between the originating server 12 and thecache server 11 in order to adapt to the terminal 10. These changes arethen indicated in the control messages inserted by the cache server 11.Thus, for example, the http get messages stored in the content deliveryfile FLC are replaced by push http2 type messages, etc.

Modifications to some messages of the content delivery file FLC may alsochange the time spacing between messages to reduce throughput, andindicate these changes in the control messages.

At the end of the replay of all the messages stored in the contentdelivery file FLC and modified during step G14, the requested content isdelivered to the terminal 10.

At the end of the replay of all the messages stored in the contentdelivery file FLC, the terminal 10 also has the protocol informationgenerated by the originating server 12 which can be used to verify theintegrity of the data transmitted by the cache server 11.

In a second alternative of the methods objects of the development, themodifications to be applied to some messages of the content deliveryfile FLC are performed at the terminal 10. The terminal 10 modifies someparameters of the messages stored in the content delivery file FLC thathas been transmitted to the terminal 10 as a function of the protocolinformation generated by the originating server 12, and itself comprisedin the content delivery file FLC transmitted. In this secondalternative, the terminal 10 may use additional protocol information tomodify some messages comprised in the content delivery file FLC. Suchadditional protocol information is not comprised in the content deliveryfile FLC, it is transmitted separately to the terminal 10 by the cacheserver 11 in a step G15′. This is because, in this case, the protocolinformation comprised in the content delivery file FLC relates to theidentity of the messages to be modified for replay, and the additionalprotocol information relates to the values to be applied to the messagesidentified in the protocol information during modification thereof. Theadditional protocol information is generated by the cache server 11 as afunction of information received from the terminal 10. Thus, while theprotocol information may be common to several terminals, the additionalprotocol information is specific to the terminal 10.

In a first implementation of this second alternative, during a step G16,the terminal 10 modifies, creates or deletes header field values of somemessages initially exchanged between the originating server 12 and thecache server 11 for replaying, between the cache server 11 and theterminal 10, the sequence of messages recorded during step G4. The listof header field values that can be modified is for example:

[ { “op”: “replace”, “path”: “user-agent”, “value”: “Mozilla/5.0 (Linux;Android 7.0; SM-G892A Build/NRD90M; wv) AppleWebKit/537.36 (KHTML, likeGecko) Version/4.0 Chrome/60.0.3112.107 Mobile Safari/537.36” }, { “op”:“add”, “path”: “/x-nginx-cache-version”, “value”: “8.4.1”}, ]

Once the content delivery file FLC associated with the content is ready,the terminal 10 triggers, in a step G17, the replay of the messagesstored in the content delivery file FLC and modified during step G16.

In a second implementation of this second alternative, the terminal 10modifies some of the messages stored in the content delivery file FLCassociated with the requested content in order to adapt them to thesending/receiving points, when replaying these messages. Thus, in thissecond implementation of this second alternative, the messages that areto be modified are modified gradually.

As in the first implementation, the modification of messages isperformed based on the protocol information generated by the originatingserver 12.

Regardless of the implementation, modifications to some messages of thecontent delivery file FLC may also change the protocol used whendownloading the content between the originating server 12 and the cacheserver 11 in order to adapt to the terminal 10. These changes are thenindicated in the control messages inserted by the terminal 10. Thus, forexample, the http get messages stored in the HARS file are replaced bypush http2 type messages, etc.

The terminal 10 can also change the time spacing between messages toreduce throughput, and indicate these changes in the control messages.

In both the first and second alternatives, the terminal 10 has a versionof the protocol information certified by the originating server 12, sothe terminal 10 can verify, by means of the cryptographic keys received,that the modifications made by the cache server 11 or the terminal 10comply with the instructions of the originating server 12.

At the end of the replay of the messages stored in the content deliveryfile FLC and modified during step G16, the requested content isdelivered to the terminal 10.

FIG. 4 represents a terminal 10 according to an embodiment of thedevelopment. Such a terminal 10 is capable of implementing the variousembodiments of the method for accessing at least one content accordingto FIG. 3 .

A terminal 10 may comprise at least one hardware processor 41, a storageunit 42, an input device 43, a display device 44, an interface 45, andat least one network interface 46 which are connected to each otherthrough a bus 47. Of course, the constituent elements of the terminal 10may be connected by means of a connection other than a bus.

The processor 41 controls the operations of the terminal 10. The storageunit 42 stores at least one program for implementing the methodaccording to an embodiment of the development to be executed by theprocessor 41, and various data, such as parameters used for calculationsperformed by the processor 41, intermediate data of calculationsperformed by the processor 41, etc. The processor 41 may be formed byany known and appropriate hardware or software, or by a combination ofhardware and software. For example, the processor 41 may be formed bydedicated hardware such as a processing circuit, or by a programmableprocessing unit such as a central processing unit which executes aprogram stored in a memory thereof.

The storage unit 42 may be formed by any appropriate means capable ofstoring the program or programs and data in a computer readable manner.Examples of the storage unit 42 comprise non-transitorycomputer-readable storage media such as solid-state memory devices, andmagnetic, optical or magneto-optical recording media loaded into aread/write unit.

The input device 43 may be formed by a keyboard, a pointing device suchas a mouse to be used by a user to enter commands. The display device 34may also be formed by a display module, such as a Graphical UserInterface (GUI).

The interface 45 provides an interface between the terminal 10 andanother piece of equipment.

At least one network interface 46 provides a connection between theterminal 10 and the cache server 11, and the originating server 12.

FIG. 5 represents a cache server 11 capable of implementing the variousembodiments of the method for controlling access to content according toFIG. 3 .

A cache server 11 may comprise at least one hardware processor 51, astorage unit 52, and at least one network interface 53 which areconnected to each other through a bus 54. Of course, the constituentelements of the cache server 11 may be connected by means of aconnection other than a bus.

The processor 51 controls the operations of the cache server 11. Thestorage unit 52 stores at least one program for implementing the methodaccording to an embodiment to be executed by the processor 51, andvarious data, such as parameters used for calculations performed by theprocessor 51, intermediate data of calculations performed by theprocessor 51, etc. The processor 51 may be formed by any known andappropriate hardware or software, or by a combination of hardware andsoftware. For example, the processor 51 may be formed by dedicatedhardware such as a processing circuit, or by a programmable processingunit such as a central processing unit which executes a program storedin a memory thereof.

The storage unit 52 may be formed by any suitable means capable ofstoring the program or programs and data in a computer readable manner.Examples of the storage unit 52 comprise non-transitorycomputer-readable storage media such as solid-state memory devices, andmagnetic, optical or magneto-optical recording media loaded into aread/write unit.

At least one network interface 53 provides a connection between thecache server 11, the terminal 10 and the originating server 12.

1. A method for accessing content, the method being implemented by aterminal and comprising: a first phase comprising: sending a request forauthorization to access the content to an originating server associatedwith the content; receiving a file comprising at least one authorizationto access the content delivered to the terminal by the originatingserver; a second phase comprising: sending a request for access to thecontent to a cache server in which the content is stored; transmittingthe file comprising the access authorization to the cache server; andreceiving the content transmitted by the cache server when anauthenticity of the file is verified by the cache server.
 2. The methodfor accessing content according to claim 1, wherein the file comprises asequence of messages exchanged between the terminal and the originatingserver during a communication session established between the terminaland the originating server, at least one of the messages of the sequenceof messages comprising the authorization to access the content.
 3. Themethod for accessing content according to claim 1, wherein receiving thecontent comprises in replaying, with the cache server, a sequence ofmessages exchanged between the cache server (11) and the originatingserver during a communication session established between the cacheserver and the originating server during which the content is deliveredto the cache server, the sequence of messages having been recorded bythe cache server.
 4. The method for accessing content according to claim1, wherein the access authorization has a validity duration.
 5. A methodfor controlling access to content stored in a cache server by at leastone terminal, the method being implemented by the cache server andcomprising: a first phase comprising: receiving a first file comprisingdata for controlling access to the content delivered by a originatingserver associated with the content; a second phase comprising thefollowing steps of: receiving a request for access to the content sentby the terminal; receiving a second file, transmitted by the terminaland comprising at least one authorization to access the contentdelivered to the terminal by the originating server; verifying anauthenticity of the second file comprising the authorization to accessthe content by means of the first file comprising data for controllingaccess to the content; and when the authenticity of the second file isverified, delivering the content to the terminal.
 6. The method forcontrolling access to content according to claim 5, wherein the firstfile further comprises software for processing the second file.
 7. Themethod for controlling access to content according to claim 5,comprising recording a sequence of messages exchanged between the cacheserver and the originating server hosting the content during acommunication session established with the originating server associatedwith the content and during which the content is delivered to the cacheserver.
 8. The method for controlling access to content according toclaim 7, wherein the first file is delivered during the communicationsession established with the originating server.
 9. The method forcontrolling access to content according to claim 7, comprisingreplaying, with the at least one terminal, the sequence of messagesrecorded, resulting in the delivery of the content.
 10. The method forcontrolling access to a content according to claim 5, wherein the secondfile comprises a sequence of messages exchanged between the terminal andthe originating server during a communication session establishedbetween the terminal and the originating server, at least one of themessages of the sequence of messages comprising the authorization toaccess the content.
 11. A terminal requesting access to content, theterminal comprising means for: receiving a file comprising at least oneauthorization to access the content delivered to the terminal by anoriginating server associated with the content; sending a request foraccess to the content to a cache server in which the content is stored;transmitting the file comprising the access authorization to the cacheserver; and receiving the content transmitted by the cache server whenan authenticity of the file is verified by the cache server.
 12. A cacheserver capable of controlling an access to content stored in the cacheserver by at least one terminal, the cache server comprising means for:receiving a first file comprising data for controlling access to thecontent delivered by a originating server associated with the content;receiving a request for access to the content sent by the terminal;receiving a second file, transmitted by the terminal and comprising atleast one authorization to access the content delivered to the terminalby the originating server; verifying an authenticity of the second filecomprising the authorization to access the content by means of the firstfile comprising data for controlling access to the content; and when theauthenticity of the second file is verified, delivering the contents tothe terminal.